맨위로가기

경로 MTU 탐색

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

경로 MTU 탐색(Path MTU Discovery, PMTUD)은 IP 네트워크에서 송신 호스트가 분할 없이 전송할 수 있는 최대 전송 단위(MTU)를 결정하는 과정이다. IPv4에서는 '분할 금지' 플래그를 설정하여 작동하며, 경로 상의 MTU보다 큰 패킷은 삭제되고 ICMP 메시지를 통해 송신 호스트가 MTU를 줄이도록 한다. IPv6에서는 '분할 금지' 옵션이 없으므로, ICMPv6 메시지를 사용하여 MTU를 조정한다. PMTUD는 보안 장비에 의해 ICMP 메시지가 차단될 경우 연결 문제(블랙홀 연결)를 발생시킬 수 있으며, 이를 해결하기 위해 DPLPMTUD, MSS 클램핑 등의 기술이 사용된다.

더 읽어볼만한 페이지

  • 인터넷 프로토콜 - IPTV
    IPTV는 인터넷 프로토콜을 사용하여 실시간 방송, VOD 등 다양한 콘텐츠를 제공하는 텔레비전 서비스이며, 고속통신망과의 통합, 양방향 서비스 등의 장점을 가지지만 망 사업자 제한 등의 제한 사항도 존재한다.
  • 인터넷 프로토콜 - DNSSEC
    DNSSEC는 DNS의 보안 취약점을 개선하기 위해 도메인 정보에 디지털 서명을 추가하여 응답 레코드의 무결성을 보장하고 DNS 위장 공격을 막는 기술로, RRSIG, DNSKEY 등 다양한 리소스 레코드 유형을 사용하여 인증 체인을 구성하며 공개 키 암호 방식을 활용한다.
경로 MTU 탐색
경로 MTU 탐색
유형IP 네트워킹 기술
목적패킷 단편화를 피하기 위해 네트워크 경로를 통해 전송할 수 있는 최대 패킷 크기 결정
약어PMTUD
상세 정보
작동 방식송신 호스트가 IP 헤더에서 "Don't Fragment" (DF 비트)를 설정하여 패킷을 보냄
경로를 따라 MTU가 더 작은 라우터가 패킷을 삭제하고 ICMP 메시지 ("Destination Unreachable" 및 "Fragmentation Needed")를 송신 호스트로 다시 보냄
송신 호스트는 수신된 ICMP 메시지를 기반으로 경로 MTU 크기를 줄이고, 더 작은 패킷 크기로 데이터 전송을 다시 시도
문제점일부 방화벽이 ICMP 메시지를 차단하여 경로 MTU 탐색을 방해할 수 있음
IPv6에서는 중간 라우터가 더 이상 패킷을 단편화하지 않으며, 이는 경로 MTU 탐색이 필수적임을 의미
IPv6IPv6에서는 중간 라우터가 패킷을 단편화하지 않음
송신 호스트는 초기 패킷 크기를 가정하고, ICMPv6 "Packet Too Big" 메시지를 받으면 패킷 크기를 줄여 재전송
대체 방법TCP MSS Clamping: TCP 핸드셰이크 중에 최대 세그먼트 크기(MSS) 옵션을 사용하여 MTU 크기를 조정
관련 RFCRFC 1191: 경로 MTU 탐색
RFC 8201: IPv6 경로 MTU 탐색에서 ICMP 메시지 크기 제한 문제 해결
RFC 8899: 경로 MTU 탐색 신뢰성 및 성능 향상을 위한 고려 사항

2. 구현

경로 MTU 탐색은 IPv4와 IPv6에서 구현 방식이 약간 다르다. IPv4에서는 패킷 헤더에 '분할 금지' 플래그를 설정하고, IPv6에서는 링크 계층 인터페이스의 MTU를 초기 경로 MTU로 가정한다. 두 경우 모두 경로 상의 장치가 패킷을 처리할 수 없을 만큼 MTU가 작으면 ICMP 오류 메시지를 보내 송신 호스트가 경로 MTU를 조정한다. 이 과정은 패킷이 문제없이 전송될 때까지 반복된다.[3]

연결 설정 후 경로 MTU가 변경될 때, 더 작아진 MTU는 큰 패킷 전송 시 ICMP 오류를 통해 발견되지만, 더 커진 MTU는 알 수 없다.[1][2]

2. 1. IPv4

IPv4 패킷의 경우, 경로 MTU 탐색은 발신 패킷의 IP 헤더에 ''분할 금지''(Don't Fragment, DF) 플래그 비트를 설정하여 작동한다. 그러면 경로 상의 MTU가 패킷보다 작은 모든 장치는 해당 패킷을 삭제하고, MTU를 포함하는 인터넷 제어 메시지 프로토콜(ICMP) ''분할 필요''(Type 3, Code 4) 메시지를 다시 보내 소스 호스트가 경로 MTU를 적절하게 줄일 수 있도록 한다. 이 과정은 MTU가 분할 없이 전체 경로를 통과할 수 있을 정도로 작아질 때까지 반복된다.

연결이 설정된 후 경로 MTU가 변경되어 이전에 결정된 경로 MTU보다 작아지면, 첫 번째 큰 패킷이 ICMP 오류를 발생시키고 새로운 더 작은 경로 MTU가 발견된다. 경로가 변경되고 새로운 경로 MTU가 더 커져도, 소스는 증가에 대해 알 수 없다. 이는 새로운 경로를 따라가는 모든 라우터가 소스가 원래 결정한 더 작은 경로 MTU를 사용하여 전송하는 모든 패킷을 릴레이할 수 있기 때문이다.[1][2][3]

2. 2. IPv6

IPv6 라우터는 패킷을 분할하지 않으므로 IPv6 헤더에는 ''분할 금지'' 옵션이 없다. IPv6의 경우, 경로 MTU 탐색은 처음에 경로 MTU가 트래픽이 시작되는 링크 계층 인터페이스의 MTU와 동일하다고 가정하여 작동한다. 그런 다음 IPv4와 유사하게 경로 상의 MTU가 패킷보다 작은 모든 장치는 패킷을 삭제하고, 해당 MTU를 포함하는 ICMPv6 ''패킷 너무 큼''(Type 2) 메시지를 다시 보내 소스 호스트가 경로 MTU를 적절하게 줄일 수 있도록 한다. 이 과정은 MTU가 분할 없이 전체 경로를 통과할 수 있을 정도로 작아질 때까지 반복된다.[3]

연결이 설정된 후 경로 MTU가 변경되어 이전에 결정된 경로 MTU보다 작아지면, 첫 번째 큰 패킷이 ICMP 오류를 발생시키고 새로운 더 작은 경로 MTU가 발견된다. 경로가 변경되고 새로운 경로 MTU가 더 커져도, 소스는 증가에 대해 알 수 없다. 이는 새로운 경로를 따라가는 모든 라우터가 소스가 원래 결정한 더 작은 경로 MTU를 사용하여 전송하는 모든 패킷을 릴레이할 수 있기 때문이다.[1][2][3]

3. 문제점

경로 MTU 탐색(PMTUD)은 네트워크 상에서 최적의 데이터 전송 크기를 결정하는 데 중요한 역할을 하지만, 몇 가지 문제점이 존재한다.

보안을 위해 많은 네트워크 장비들이 ICMP 메시지를 차단하는 경우가 있는데, 이는 PMTUD의 작동에 필수적인 오류 메시지까지 막아버려 블랙홀 연결과 같은 문제를 일으킬 수 있다.[1] 이러한 문제를 해결하기 위해 ''데이터그램 패킷화 계층 경로 MTU 검색''(DPLPMTUD)과 같은 방법이 표준화되기도 했다.[2]

리눅스 커널[4]이나 시스코[5] 라우터는 TCP 연결 설정 시 최대 세그먼트 크기(MSS)를 조정하는 ''MSS 클램핑'' 기능을 제공하여 이 문제를 완화하기도 한다.

네트워크 관리자가 MTU 설정을 제대로 관리하지 않아 문제가 발생하는 경우도 있다. 특히, 여러 레이어 2 세그먼트로 구성된 네트워크 환경에서, 중간 스위치가 낮은 MTU를 가진 세그먼트에서 패킷을 조용히 삭제해 버리는 문제가 발생할 수 있다.[5]

3. 1. 블랙홀 연결

많은 네트워크 보안 장비는 PMTUD의 적절한 작동에 필요한 오류 메시지를 포함하여 모든 ICMP 메시지를 차단하여 보안상의 이점을 얻으려고 한다. 이로 인해 TCP 3방향 핸드셰이크를 정상적으로 완료했지만 데이터를 전송하려 할 때 멈추는 연결이 발생할 수 있다. 이러한 상태를 '''블랙홀 연결'''이라고 한다.[1]

PMTUD의 일부 구현은 대용량 페이로드 패킷이 링크 혼잡이 아닌 MTU로 인해 삭제되었다고 추론하여 이 문제를 해결하려고 시도한다. 이러한 방식 중 하나가 RFC 8899, ''데이터그램 패킷화 계층 경로 MTU 검색''(DPLPMTUD)으로 표준화되었다.[2] 연결 손실 시 DPLPMTUD는 제어된 크기의 ''프로브 패킷''을 사용하여 경로의 MTU를 조사한다. 프로브 패킷의 응답은 경로 MTU가 해당 패킷의 크기 이상임을 나타낸다. DPLPMTUD의 사용은 QUIC에서 표준화되었다.[3] 그러나 전송 계층 프로토콜이 가장 효율적으로 작동하려면 ICMP ''Unreachable'' 메시지(유형 3)가 여전히 허용되어야 한다.

리눅스 커널[4] 및 시스코[5]를 포함한 일부 라우터는 해결책으로 TCP 핸드셰이크에서 광고되는 최대 세그먼트 크기(MSS)를 줄이는 옵션을 제공한다. 이를 ''MSS 클램핑''이라고 한다.

또 다른 문제는 네트워크 관리자가 2개의 인접한 레이어 3 홉 사이의 MTU를 제대로 업데이트하지 않는 경우다. 이러한 홉 사이의 링크가 스위치가 있는 여러 레이어 2 세그먼트로 구성된 경우 발생한다. 일반적으로 발신 L3 인터페이스의 MTU는 첫 번째 L2 세그먼트에서 가져온다. 그러나 두 번째 또는 그 이후의 세그먼트가 더 낮은 MTU를 가지면 그 사이에 있는 스위치는 ICMP를 반환하지 않고 패킷을 조용히 삭제한다(ICMP "패킷이 너무 큼"은 레이어 3 홉만 생성할 수 있기 때문이다). 따라서 이 경우 관리자는 다음 L3 홉까지 사용된 레이어 2 세그먼트의 최소 MTU로 각 발신 L3 인터페이스의 MTU를 업데이트해야 한다.

3. 2. MSS 클램핑

일부 라우터는 TCP 핸드셰이크에서 광고되는 최대 세그먼트 크기(MSS)를 줄이는 옵션을 제공하여 해결책을 제시하는데, Linux 커널[4] 및 시스코(Cisco)[5] 등이 이에 해당한다. 이를 ''MSS 클램핑''이라고 한다.

3. 3. 레이어 2 MTU 불일치

많은 네트워크 보안 장비는 PMTUD의 적절한 작동에 필요한 오류 메시지를 포함하여 모든 ICMP 메시지를 차단하여 보안상의 이점을 얻으려고 한다. 이로 인해 TCP 3방향 핸드셰이크를 정상적으로 완료했지만 데이터를 전송하려 할 때 멈추는 연결이 발생할 수 있다. 이러한 상태를 ''블랙홀 연결''이라고 한다.[4]

또 다른 문제는 네트워크 관리자가 2개의 인접한 레이어 3 홉 사이의 MTU를 제대로 업데이트하지 않는 경우이다. 이러한 홉 사이의 링크가 스위치가 있는 여러 레이어 2 세그먼트로 구성된 경우 발생한다. 일반적으로 발신 L3 인터페이스의 MTU는 첫 번째 L2 세그먼트에서 가져온다. 그러나 두 번째 또는 그 이후의 세그먼트가 더 낮은 MTU를 가지면 그 사이에 있는 스위치는 ICMP를 반환하지 않고 패킷을 조용히 삭제한다(ICMP "패킷이 너무 큼"은 레이어 3 홉만 생성할 수 있기 때문이다). 따라서 이 경우 관리자는 다음 L3 홉까지 사용된 레이어 2 세그먼트의 최소 MTU로 각 발신 L3 인터페이스의 MTU를 업데이트해야 한다.[5]

4. DPLPMTUD

많은 네트워크 보안 장비는 PMTUD의 적절한 작동에 필요한 오류 메시지를 포함하여 모든 ICMP 메시지를 차단하여 보안상의 이점을 얻으려고 한다. 이로 인해 TCP 3방향 핸드셰이크를 정상적으로 완료했지만 데이터를 전송하려 할 때 멈추는 연결이 발생할 수 있다. 이러한 상태를 ''블랙홀 연결''이라고 한다.[4]

PMTUD의 일부 구현은 대용량 페이로드 패킷이 링크 혼잡이 아닌 MTU로 인해 삭제되었다고 추론하여 이 문제를 해결하려고 시도한다. 이러한 방식 중 하나가 RFC 8899, ''데이터그램 패킷화 계층 경로 MTU 검색''(DPLPMTUD)으로 표준화되었다.[5] 연결 손실 시 DPLPMTUD는 제어된 크기의 ''프로브 패킷''을 사용하여 경로의 MTU를 조사한다. 프로브 패킷의 응답은 경로 MTU가 해당 패킷의 크기 이상임을 나타낸다. DPLPMTUD의 사용은 QUIC에서 표준화되었다. 그러나 전송 계층 프로토콜이 가장 효율적으로 작동하려면 ICMP ''Unreachable'' 메시지(유형 3)가 여전히 허용되어야 한다.

Linux 커널[4] 및 시스코[5]를 포함한 일부 라우터는 해결책으로 TCP 핸드셰이크에서 광고되는 최대 세그먼트 크기(MSS)를 줄이는 옵션을 제공한다. 이를 ''MSS 클램핑''이라고 한다.

참조

[1] 서적 Internetworking with TCP/IP Volume 1 Pearson
[2] 문서 linux source code (ipv4) https://github.com/t[...]
[3] 서적 Understanding IPv6 Microsoft Press 2012
[4] 웹사이트 Mangling packet headers - nftables wiki https://wiki.nftable[...] 2024-07-03
[5] 웹사이트 Ethernet MTU and TCP MSS Adjustment Concept for PPPoE Connections https://www.cisco.co[...] 2024-07-03



본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com